Input/Output (“I/O”) operations encompass all types of actions and communications between a computer and its users and/or its processing, storage or peripheral devices, as well as with other system computers (via a network such as a local area network (“LAN”) or a wide area network (“WAN”) or the Internet using a communications protocol such as Transmission Control Protocol over Internet Protocol (TCP/IP)) or the outside world; including “read” operations (where information is extracted from a stored location in a system or network device) as well as “write” operations (where information is stored in a system or network location) and “transfer” operations (where information is transmitted from one system or network location or device to another). I/O “event completion” models are based upon use of application programming interfaces (APIs) that allow a software application to communicate with a computer or network operating system for the purpose of requesting performance of a particular I/O operation. When such I/O operations take place over a computer system or network, I/O “read” and/or “write” (or other) requests are made by a “user code” (or “thread”) of the requesting application in order to send (or retrieve) data or instructions for the purpose of transmitting them from one system or network location or device to another.
System or network communication software often needs to provide “timeout” functionality for the reading and writing of data or instructions (and other I/O operations) in order to allow the next I/O request to be processed in the event that some system event or problem prevents processing of the current request. For example, a “read” I/O request will expire (or “timeout”) within a certain period of time (often seconds) if the read operation has not been completed by that time after a “read” API has been called by the “user code” to execute that request. Most of the time such an I/O request will be completed within the required “timeout” period, and the “timeout” will not be signaled to the calling code for execution. However, problems can occur if the system or network is not optimized for performance in a way that prevents system processing resources from being unnecessarily used to schedule and cancel possible timeout actions. For example, if 10,000 “read” requests are initiated during a 5 second time interval and each of them has a timeout that is scheduled to occur within 60 to 120 seconds after initiation of the request, and each read is subsequently executed within 30 seconds after its initiation, then the system resources that were used to schedule (and subsequently cancel) those “timeout requests” were wasted by being occupied with those requests instead of contributing to system processing activity (or “through-put”).
Most system or network “timeout” algorithms involve keeping track of when outstanding I/O requests will “timeout” through use of a list that is periodically checked (for example once per second) to determine whether the timeout (expiration) time has been reached for a given request, and if so a “timeout action” is taken to cancel the associated I/O operation. The list is then accessed to remove a “timeout entry” when its I/O operation has been timely completed so that it will not be errantly triggered. However, the processing of such “timeout lists” causes a significant degradation in system performance, since the list must be ordered according to the point in time when an entry will timeout due to expiration of its I/O request, requiring the list to be searched for the proper location to insert a new entry (as well as for removal of an entry when it is no longer needed due to timely execution of the request). Such a list must also be periodically processed to find any “active” entry requiring a “timeout action” to be taken due to expiration of its I/O operation without completion. Software synchronization logic is required to coordinate the timing of most of these types of “list manipulation actions” with a further resulting degradation in system processing performance.